OTN (Optical Transport Network) is a standard which defines an encapsulation protocol permitting the optical transmission of a wide variety of different signals over a common optical medium. OTN provides the flexibility for transparently multiplexing and mapping synchronous and/or asynchronous client signals (each of which may be represented in their own standard protocols) over fiber-optic networks, including optical networks employing Wavelength Division Multiplexing (WDM). The OTN standard was developed by the ITU-T, which defines OTN as a set of Optical Network Elements (hereinafter referred to as “nodes”) connected by optical fiber links, able to provide the functionality of transport, multiplexing, switching, management, supervision, and survivability of optical channels carrying client signals. ITU Standard G.709 defines various aspects of OTN, and may be referred to as a “digital wrapper” technology which defines a layer hierarchy for payload encapsulation, Operations, Administration, Maintenance (OAM) overhead, forward error correction (FEC), and multiplexing. The result is a transport standard that includes the benefits of Sonet/SDH (such as resiliency and manageability) but with improvements for transporting asynchronous data payloads such as Gigabit Ethernet. Accordingly, OTN was specifically designed to be a multiservice transport container for essentially any type of data service, from TDM to packet, and this flexibility is one of OTN's advantages. OTN has been widely deployed for transport within long-haul networks, particularly because the inherent FEC features enable optical transmission over longer distances.
FIG. 1 shows a simplified diagram of an exemplary OTN layer hierarchy 100 and its associated frame structures 150 defined in ITU G.709. The OTN layer hierarchy 100 may be broadly divided into four layers, Optical Payload Unit (OPUk) 104, Optical Data Unit (ODUk) 106, Optical Transport Unit (OTUk) 108, and Optical Channel (OCh) 109. Because various OTN layers may exchange data using a variety of different rates, e.g., OTU1, OTU2, and OTU3, and ODU0, these rates may be collectively referred to as having a “k” appended to the appropriate layer's acronym, such as “ODUk” and “OTUk.” The OPUk layer 104, ODUk layer 106, and the OTUk layer 108 operate in the electrical domain. The OCh layer 109 operates in the optical domain.
End user services, which are referred to herein as “Clients” 102, may provide Client signal frame 152 in a variety of different protocols to the OPUk layer 104. The Client signal frame 152 may include signals using synchronous networking protocols, such as SONET and SDH, and/or asynchronous protocols, such as ATM, Ethernet, and/or Fibre Channel. The OPUk layer 104, which contains all the timeslots in the OTN frame, may encapsulate the Client signal frame 152, and add OPUk overhead, to produce an OPUk frame 154. The Client signal frame 152 is essentially unmodified by the network, aside from being mapped at the source node and demapped at the sink node. The ODUk layer 106, which provides path level transport functions, receives the OPUk frame 154, appends its own ODUk overhead, and encapsulates the OPUk frame 154 to produce an ODUk frame 156. The OTUk layer 108, which provides section-level overhead, receives the ODUk frame 156, appends its own OTUk overhead and Forward Error Correction (FEC) information, and encapsulates the ODUk frame 156 to produce an OTUk frame 158. The OCh layer 109 serializes a plurality of OTUk frames 158, and appends its own overhead to produce the OCh frame 159.
Because OTN serves as a “digital wrapper” for a variety of synchronous and asynchronous signals using different protocols as noted above, the OTUk frame timing may be based on the ODUk layer frame timing. An OTN node performing connections at the ODUk layer, moves ODUk connections (in or out) from one OTUk to another. When the ODUk frame mapped into an OTUk frame changes, the OTUk frame timing will typically change. This change in timing can cause an Out-Of-Frame (OOF) condition at one or more downstream nodes. The downstream nodes should adjust to the change in OTUk frame timing and transition back to an in-frame (IF) state within a period of time defined as the OOF interval.
During this OOF interval, the shift of the OTUk frame may cause the downstream nodes to look in the wrong locations for various status bits, and subsequently detect invalid defects which should not be reported and acted upon by the network. However, conventional control elements within the network may not be able to ascertain that the reported defects are invalid, and thus may unnecessarily consume resources attempting to address these “defects” which otherwise could be safely ignored.